Network Working Group Vinton G. Cerf
Request for Comments: 635 Stanford Üniversitesi
NIC: 30489
ARPANET Protokollerinin Bir Değerlendirmesi
ÖZET
Bu makale, ARPANET iletişim protokollerinin yeniden tasarlanması için bazı kuramsal ve pratik gerekçeleri sunmaktadır. Çok paketli mesajlar, Host yeniden iletimi, kopya algılama, sıralama ve onaylama ile ilgili konular ele alınmaktadır. Yeni Host düzeyi protokollerinin benimsendiği varsayımı altında IMP/IMP protokolüne yönelik sadeleştirmeler önerilmektedir. Tartışmaların birçoğu mevcut protokol tasarımındaki ayrıntılara atıfta bulunduğundan, güncel protokol tasarımlarına aşinalık muhtemelen gereklidir.
RFC 635 — ARPANET Protokollerinin Bir Değerlendirmesi — Mayıs 1974
Giriş
Advanced Research Project Agency kaynak paylaşımı bilgisayar ağı (ARPANET) [6] tarihçesi, birçok açıdan protokollerin incelenmesi, geliştirilmesi ve uygulanmasının tarihçesidir. Ağın erken geliştirme döneminde, protokol tasarımı çalışmalarına birçok önemli kavram keşfedilmiş ve dahil edilmiştir. Protokol katmanlaması (ağ iletiminin farklı düzeylerinin işlevsel olarak ayrılması), Hosttan Hosta bağlantıların kurulması için ikili buluşma kavramı [1,2] ve Terminalden Hosta protokolün tanımlanmasına yardımcı olmak üzere bir Ağ Sanal Terminalinin tanımlanması [3,14] önemli erken fikirlerin tümüne örnektir. ARPANET tasarım ekiplerinin karşılaştığı görevler çoğu zaman belirsizdi ve sıklıkla daha önce hiç düşünülmemiş anlaşmalar gerektiriyordu (örneğin, farklı işletim sistemleri ve donanımların iletişim kurabilmesini sağlayacak ortak protokoller). Çabanın başarısı, geriye dönüp bakıldığında, şaşırtıcıdır ve ARPANET’i bir araya getirme işine kendilerini adamaya istekli olanlara büyük ölçüde teşekkür borçludur.
ARPANET’in ilk başlatılmasından bu yana geçen beş yıl içinde, kullanımda olan protokollerin tasarımı ve davranışı hakkında çok şey öğrenilmiştir. IMP’ten IMP’ye protokol [4] sürekli olarak gözden geçirilmiş ve HOST/IMP arayüz belirtimi [5] küçük değişiklikler geçirmiştir. Geriye dönük olarak ve deneyim ışığında, şu anda kullanımda olan tasarım ve uygulamaların bazı yönlerini yeniden değerlendirmek makul görünmektedir. Ayrıca, dünya genelinde ulusal bilgisayar ağı projelerinin hızlı gelişimi, uluslararası bağlantıların gerçekleştirilebilmesi için iletişim protokollerinin tasarımında uluslararası işbirliği ihtiyacını vurgulamaktadır.
Bu makale, ARPANET’teki HOSTtan HOSTa, IMP’ten IMP’ye ve HOST/IMP iletişim protokollerinin yeniden tasarlanmasına yönelik gerekçelerle ilgilenmektedir. Mevcut protokollerden elde edilebilecek kuramsal aktarım kapasitesi ve gecikme analizleri ile bunlardaki bazı zayıflıkların tartışması da dahil edilmiştir.
Bu raporda ulaşılan temel sonuçlar şunlardır:
- a) Çok paketli mesaj olanakları, potansiyel aktarım kapasitesinde bir kayıp olmaksızın ve IMP yazılımında eşzamanlı bir sadeleştirme ile ortadan kaldırılabilir. [8]
- b) Hedef IMP tarafından hedef HOSTa teslim edilen mesajların sıralanması, daha önceki bir IMP protokolü sürümünde çok paketli mesajların yeniden birleştirilmesiyle bağlantılı olarak yaşanan yeniden birleştirme kilitlenmesine benzer bir kilitlenme durumuna yol açabilir [7]. Hostlar zaten gelen mesajları sıralamak zorundadır; dolayısıyla IMP’nin bunu yapmasına gerek yoktur.
- c) HOST/IMP protokolü, hedef IMP’nin gelen paketleri HOSTa teslim etmeden önce yeniden birleştirmesine veya yeniden sıralamasına gerek kalmadığı sürece, HOSTtan IMP’ye keyfi uzunlukta mesajların gönderilmesine izin verecek şekilde değiştirilebilir.
- d) Host düzeyinde yeniden iletim, olumlu uçtan uca onaylar, hata algılama, kopya algılama ve mesaj sıralama; IMP/IMP protokolündeki bu özelliklerin birçoğuna ve mevcut HOST/IMP protokolündeki Sonraki Mesaj İsteği (RFNM) mekanizmasına olan ihtiyacı ortadan kaldırabilir.
- e) Mevcut HOST–HOST protokolündeki akış denetimi mekanizması, mesaj kaybı veya çoğaltılması nedeniyle eşzamanlılığını yitirebilir.
- f) Host düzeyi bağlantılar tam çift yönlü olmalıdır.
- g) Ayrı bir HOST/HOST denetim bağlantısına duyulan ihtiyaç, denetim bilgisinin her Host iletiminin başlığında taşınmasıyla ortadan kaldırılabilir.
Aktarım Kapasitesi ile İlgili Hususlar
IMP alt ağı, Host çiftleri arasında saniyede 80 kb’ye kadar veri iletebilmesine rağmen¹, Host yazılımı kullanan neredeyse hiçbir uygulama bu değere ulaşamamıştır. 1971 yılında Tinker ve McClellan Hava Kuvvetleri Üsleri arasında yapılan bir deneyde 40 kb/sn’ye kadar ani hızlar elde edilmiştir; ancak bu, birden fazla mantıksal bağlantı üzerinden veri ileten ve güvenilir, sıralı iletim sağlamak için Host düzeyinde yeniden birleştirme ve onaylama kullanan standart dışı bir Host/Host protokolünün kullanılmasıyla sağlanmıştır². Aşağıdaki analiz, mevcut Host/Host protokolünün, mesaj biçimi ek yükü nedeniyle tek bir bağlantı üzerinde 40 kb/sn’den fazlasını sunamayacağını ve iletişim kuran Hostlar birkaç IMP ile ayrıldığında bu değerin hiperbolik olarak düştüğünü göstermektedir.
Host/Host aktarım kapasitesinin mesafeye (atlama sayısına) bağlı davranışının tek temel nedeni, "tek seferde tek mesaj" Host/Host protokolüdür. Bu, Hostlardaki süreçler arasındaki belirli bir bağlantı üzerinde, herhangi bir anda yalnızca 0–8063 bit veri içeren tek bir mesajın beklemede olabileceği anlamına gelir. Host/Host protokolü ilk tasarlandığında, IMP’ler Host çiftleri arasında 256’ya kadar tek yönlü mantıksal bağlantı sağlıyordu. Bir bağlantı üzerinden bir mesaj gönderildiğinde (bağlantı ile mantıksal hat arasında bire bir ilişki vardı), hedef IMP’den mesajın Hosta teslim edildiğini belirten bir RFNM alınana kadar bağlantı bloke ediliyordu. Elbette, RFNM’nin ortaya çıkmaması durumuna karşı mekanizma bir zaman aşımı ile korunuyordu.
IMP protokolü o zamandan bu yana önemli ölçüde değiştirilmiştir ve artık kullanılan bağlantılardan ve hangi Hostların iletişim kurduğundan bağımsız olarak, IMP çiftleri arasında n adede kadar mesajın³ aynı anda beklemede olmasına izin vermektedir.
Bu son nokta, aynı hedef IMP ile iletişim kuran Hostların, aynı IMP’ye bağlı olmaları durumunda aralarında bir miktar etkileşim olabileceği anlamına gelir.
Host/Host protokolü, birden fazla mesaj olasılığından yararlanacak şekilde değiştirilmemiştir ve mümkün olan en yüksek aktarım kapasitesine ulaşamamaktadır. Şekil 1’de, çok paketli bir mesajın kaynaktan hedefe doğru birkaç IMP üzerinden geçerken zamana bağlı davranışı gösterilmektedir.
Bir m-paketli mesaj için h IMP tarafından paket işleme
------------------------------------
IMP(0) | pkt(0) | pkt(1) | ... | pkt(m-1) |
------------------------------------
| | ------------------------------------
IMP(1) | | | pkt(0) | pkt(1) | ... | pkt(m-1) |
| | ------------------------------------
| | | :
| | | :
| | | ------------------------------------
IMP(h-1)| | | | pkt(0) | pkt(1) | ... | pkt(m-1) |
|<------>| |<- ------------------------------------
\ \
\ `---> IMP0’dan IMP1’e yayılım gecikmesi
`--> paket iletim gecikmesi
Şekil 1
Şekil 1 çeşitli açılardan basitleştirilmiştir. İlk olarak, herhangi bir karışan trafik gösterilmemiştir; ayrıca hiçbir paket sırasız gelmemiş veya alternatif yollar üzerinden yönlendirilmemiştir. İkinci olarak, tüm paketlerin aynı azami boyutta olduğu varsayılmıştır. Ayrıca şekil, Hostlara ve Hostlardan olan iletim gecikmesini göstermemektedir. Bu nedenle, analizin sonuçları biraz iyimser olacaktır.
Hostlar arasındaki mantıksal bağlantı, h + m − 1 paket süresinin yalnızca m paket süresi boyunca meşgul olacaktır. Kaynak IMP, mesajı komşu bir IMP’ye göndermek için m paket iletim süresi boyunca meşgul olacaktır. İlk paketin son biti, yayılım gecikmesi hesaba katılmadan, h paket iletim süresinden sonra hedef IMP’ye ulaşacaktır ve kalan m − 1 paket m − 1 paket iletim süresinden sonra varışını tamamlayacaktır. Kaynak Host, hedef IMP’den bir RFNM aldıktan sonra başka bir mesaj iletmesine izin verilecektir. RFNM aslında, mesaj yeniden birleştirildikten, ilk paket teslim edildikten ve hedef IMP başka bir azami uzunlukta çok paketli mesaj için yeterli boş tampon alanına sahip olduktan sonra gönderilir⁴. Dolayısıyla yeni bir iletim, en az h + m − 1 paket süresi geçmeden gerçekleşemez; bu nedenle meşguliyet oranı yalnızca m / (h + m − 1)’dir.
IMP’ler arasındaki gerçek bant genişliği, Host/Host ve IMP/IMP denetimi için gereken ek bitler nedeniyle 50 kb/sn⁵’den 40 kb/sn’ye düşmektedir. IMP’ler tüm komşularına periyodik yönlendirme mesajları gönderir (her 0,640 saniyede bir)⁶ ve bunlar ek bant genişliği tüketir. Kaynak IMP’den hedef IMP’ye kadar kullanılabilir 50 kb/sn bant genişliğinin nominal oranını tahmin edebilir ve bunu bağlantı başına kesirli meşguliyet süresiyle çarparak bağlantı başına azami aktarım kapasitesi için iyimser bir üst sınır elde edebiliriz.
Beklenen Aktarım Kapasitesi Sınırlarının Analizi
W bitlik doğal sözcük uzunluğuna sahip bir Host tarafından iletilecek metin bitlerinin sayısı T olsun. Host/Host mesaj biçimi, 32 bitlik bir lideri, ardından 40 bitlik bir öneki ve ardından gönderilecek metni içerir. Gönderen bir Hostun, mesaj metninden önce gelen 72 bit dahil olmak üzere, sözcüklerinin tam sayılı bir katını ileteceğini varsayacağız. Ayrıca, Host/IMP arayüzü her mesaja bir bit ekler ve ardından tüm yapıyı 16 bitlik IMP sözcüklerinin tam sayılı bir katı haline getirmek için gereken sayıda sıfır ekler (IMP, bir Honeywell 316 veya 516 bilgisayarıdır).
Metni T bit içeren bir Host mesajındaki toplam bit sayısı Denklem (1) ile verilir:
[ M(T,W) = B_1(T) + B_2(T,W) + B_3(T,W) \tag{1} ]
burada:
- (B_1(T) = T + 72)
- (B_2(T,W) = -B_1(T) \bmod W)
- (B_3(T,W) = 1 + (-B_1(T) - B_2(T,W) - 1) \bmod 16)
(B_1(T)), lider, önek ve metni içeren Host mesajındaki bit sayısıdır. (B_2(T,W)), (B_1(T))’yi Host sözcüklerinin tam sayılı bir katı yapmak için gereken bit sayısıdır ve (B_3(T,W)) toplamı 16 bitlik IMP sözcüklerinin tam sayılı bir katı yapmak için gereken bit sayısıdır.
(M(T,W)) bitleri aşağıdaki şekilde paketlere dönüştürülür. 32 bitlik lider çıkarılır ve kalan sözcükler, her biri 32 bitlik liderden gelen verileri içeren 96 bitlik bir başlıkla öncelenmiş, en fazla 1008 bit veri içeren paketlere bölünür. Bu paketler komşu bir IMP’ye iletilirken, 48 bitlik denetim sekizlileri ve 24 bitlik çevrimsel sağlama toplamından oluşan bir hat denetim zarfı içine alınır. Tüm paketleri taşımak için gereken bit sayısını aşağıdaki gibi hesaplayabiliriz:
[ P(T,W) = \left( \frac{M(T,W) - 33}{1008} + 1 \right) \times 168 + M(T,W) - 32 \tag{2} ]
- T* bit Host metni iletilirken hat iletim verimliliği şu şekilde verilir:
[ LTE(T,W) = \frac{T}{P(T,W)} \tag{3} ]
H atlama uzunluğunda olan bir mantıksal hattın, T metin bitine sahip bir Host mesajını taşırken meşgul olabileceği beklenen zaman kesri şu şekilde verilir:
[ EBF(T,W,H) = \frac{P(T,W)}{H \times \min[P(T,W), 1176] + \max[P(T,W) - 1176, 0]} \tag{4} ]
(EBF(T,W,H)), daha önce hesaplanan kesrin (m / (m + h − 1)) geliştirilmiş bir biçimidir.
(EBF(T,W,H))’nin payı, kaynak IMP’den iletilmesi gereken bit sayısıdır. Payda, bir mesajın tek bir tam paketten daha kısa olması durumunu ele almak için min ve max işlevlerini kullanır. Her durumda, ilk paketin teslimi H atlama gerektirir ve kalan bitler, tüm mesaj hedef IMP’ye ulaşana kadar bu paketi izler. (Hat üzerinde DLE iki katına çıkarılabildiğinden, bu hesaplama DLE’nin hiçbir zaman veri olarak gönderilmediğini varsayar.)
Yönlendirme mesajları 1024 bit metin ve 136 bit paket başlığı ve hat denetimi gerektirir ve her IMP tarafından tüm bitişik komşularına her 0,640 saniyede bir gönderilir. Yönlendirme mesajları için gereken bant genişliği dolayısıyla (1160 / 0,640 = 1,8) kb/sn’dir.
Dolayısıyla, H atlama üzerinden gönderilen ve T metin biti içeren Host mesajları için beklenebilecek bant genişliği Denklem (5)’te ifade edilmiştir:
[ B(T,W,H) = EBF(T,W,H) \times LTE(T,W) \times (50 - 1,8) \text{ kb/sn} \tag{5} ]
(B(T,W,H)) aşağıdaki karmaşıklaştırıcı etkenlerin bir kısmını göz ardı eder:
- a) RFNM gönderimi için gecikme ve çok paketli mesajlar için kaynak IMP’ye örtük alan ayırımı.
- b) Host/IMP ve IMP/IMP arasındaki yayılım gecikmeleri.
- c) Ara IMP’lerdeki kuyruklama gecikmeleri.
- d) Yeniden iletim gecikmeleri.
Buna rağmen, (B(T,W,H)) mevcut ARPANET Host/Host protokolü kullanılarak beklenebilecek bant genişliği için iyimser bir tahmin sunar.
Çok paketli bir mesajın paketlerinin alternatif yollar üzerinden (örneğin iki adet 50 kb/sn yol) gönderilmediği varsayımı örtük olarak yapılmaktadır. IMP alt ağındaki alternatif yönlendirme, bant genişliğini artırmak için değil, tıkanık alanlardan kaçınmak için kullanıldığından, bu varsayım ARPANET’te günümüzde bulunan düşük trafik yoğunlukları için muhtemelen geçerlidir.
¹ UCLA’da R. Kahn ve V. Cerf tarafından yürütülen yayımlanmamış ölçüm deneyleri bunu doğrulamıştır.
² UCLA’daki ARPA Ağ Ölçüm Merkezinde V. Cerf tarafından elde edilen yayımlanmamış ölçüm verileri.
³ Günümüzde dört olup, bu sınır IMP tampon alanı tarafından dayatılmaktadır.
⁴ Eğer 1 saniye sonra hiçbir alan mevcut değilse, RFNM yine de gönderilir.
⁵ Bazı IMP’lerde 230 kb/sn veya 9,6 kb/sn hatlar vardır, ancak çoğunda 50 kb/sn’dir.
⁶ Bu aralık hat hızı ve yüke bağlıdır ve 128 ms kadar düşük olabilir.
B(T,W,H), 32 bitlik bir Host (W = 32) ve çeşitli mesaj metni uzunlukları ile atlama sayıları için Şekil 2’de çizilmiştir. Görüldüğü gibi, tek bir mantıksal bağlantı üzerinde tek seferde tek mesaj iletiminin etkisi, artan atlama sayıları için çok belirgindir. Uydu kanalı durumunda, hem mesaj hem de geri dönen RFNM için uzun yayılım gecikmesi (yukarı ve aşağı toplam 1/4 saniye) nedeniyle eğriler daha da düşük olacaktır.
42 ||
||
40 |||
|||
38 |||8
1||78
36 12|78
12||78
34 123|678
123456 78
32 1 23456 78
1 2 3456 78
30 1 2 3 45 6 7 8
1 2 3 45 6 7 8
28 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
26 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
24 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
22 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
20 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8 (8 Paket, 7992 bit)
18 1 2 3 4 5 6 7 (7 Paket, 7000 bit)
1 2 3 4 5 6 (6 Paket, 5976 bit)
16 1 2 3 4 5
1 2 3 4 5 (5 Paket, 4984 bit)
14 1 2 3 4
1 2 3 4 (4 Paket, 3960 bit)
12 1 2 3
1 2 3 (3 Paket, 2968 bit)
10 1 2
1 2
8 2 (2 Paket, 1944 bit)
1
6
1
4 1 (1 Paket, 952 bit)
2
1 2 3 4 5 6 7 8 9 10
Atlama Sayısı
Tek Bağlantı Kaynaktan Hedef Ana Bilgisayara Aktarım Hızı (32 bit Sözcük Ana Bilgisayarı)
Şekil 2
Çok Paketli İleti Sorunu
Özgün IMP sistemi, tek bir bağlantı üzerinde aynı anda yalnızca bir iletiye izin veriyordu; bu nedenle, tek paketli iletilerin sağlayabileceğinden daha yüksek bant genişliğine olanak tanıyacak bir yönteme ihtiyaç vardı. Bu, bir ölçüde, tek bir iletide sekiz pakete kadar izin verilerek sağlandı.
Ancak kısa süre içinde, ayrı mantıksal bağlantılar üzerinde çok paketli iletiler gönderen bir Ana Bilgisayarın, hedefte bir kilitlenme durumuna yol açabileceği keşfedildi ve bu durum ilk kez R. Kahn ve W. Crowther [7] tarafından tanımlandı. Özünde, hedefte, birden fazla bağlantı üzerinde iletimde olan tüm çok paketli iletileri yeniden birleştirmek için yeterli alan bulunmayabilirdi. Ana Bilgisayar iletime devam ederse bu durum kendini sürdüren bir hâl alıyordu; her ne kadar hedef, bir zaman aşımından sonra yeniden birleştirilmemiş çok paketli iletileri atabilse de. Bu durum ya ağın geri kalanına doğru geri basınç oluşturuyor ya da en iyi ihtimalle ağda ileti kaybına neden oluyordu.
Sonunda uygulanan çok paketli yeniden birleştirme kilitlenmesi sorununa çözüm, kaynağın IMP’sinin, çok paketli iletiyi göndermeden önce hedef IMP’de yeniden birleştirme arabellek alanı ayırmasını gerektiriyordu.
Aslında bu sorun, hedef IMP’nin Ana Bilgisayara teslim edilen iletileri sıralamasından kaynaklanabilen daha genel bir sorunun yalnızca bir örneğidir.
İletilerin Sıralanması
IMP sistemi, iletilerin bir hedef Ana Bilgisayara, bir kaynak Ana Bilgisayardan ayrıldıkları sırayla teslim edileceğini garanti eder. Bu hizmet, yeterli sayıda ileti hedef IMP’ye doğru iletimdeyse, yeniden birleştirme kilitlenmesine benzer bir kilitlenmeye neden olabilir. Tek paketli iletiler, hedefte önceden bir ayırma yapılmaksızın gönderilir ve onlar için yer mevcutsa, kaynağın IMP’sine bir RFNM geri gönderilir. Eğer yer yoksa, örtük bir ayırma isteği hedef IMP’de kuyruğa alınır. Yer kullanılabilir hâle geldiğinde, kaynağın IMP’sine bir ayırma iletisi gönderilir ve kaynak IMP tek paketli iletiyi yeniden gönderir. Kaynak IMP, iletilen ilk kopyadan bir RFNM alana kadar ya da artık ikinci bir kopyanın kabul edilebileceğini belirten bir ayırma iletisi alana kadar tek paketli iletinin bir kopyasını yeniden gönderim için saklar.
Bu düzen, belirli bir Ana Bilgisayarın iletimde çok fazla iletiye sahip olması durumunda ya da farklı IMP’ler tarafından hizmet verilen birçok Ana Bilgisayarın aynı hedef için iletimde çok fazla iletiye sahip olması durumunda başarısız olabilir. Bunun nedeni, hedef IMP’nin sıradan gelmeyen paketleri kabul etmesi ve hedef Ana Bilgisayara iletilmek üzere yeniden sıralanabilene kadar arabellekte tutmasıdır.
Günümüzde, bir kaynak IMP, belirli bir hedef için aynı anda iletimde olabilecek ileti sayısını (uzunluğundan bağımsız olarak) en fazla dört ile sınırlar. Bu, kilitlenme olasılığını esasen azaltır; ancak sıfırlamaz, çünkü aynı hedef için farklı IMP’lerden yeterli sayıda bekleyen ileti, yine de bir kilitlenmeye yol açabilir.
Bu tür kilitlenmelere karşı da, hedefte teslim edilmemiş iletilerin zaman aşımına uğratılması ve atılması yoluyla koruma sağlanır. Zaman aşımı, onlarca saniye mertebesindedir. IMP alt ağı bu tür durumlardan kurtulabilse de, hedefte iletilerin kasıtlı olarak atılmasından ya da bir IMP’nin çökmesi sonucu tüm paketlerini kaybettiği felaket niteliğindeki arızalardan kaynaklanan ileti kaybından kurtulmak için Ana Bilgisayarların zaman zaman iletileri yeniden göndermeye hazır olması gerektiği açıktır.
Dipnot: Kahn, bu durumun 1967 yılında ortaya çıkabileceğini aslında biliyordu; ancak Mart 1970’te bir ileti üreteci kullanarak ağı taşırıp gerçekten kilitleyene kadar meslektaşlarını ikna edemedi.
Dipnot: R. Kahn, L. Kleinrock ve H. Opderbeck, IMP’lerin sıradan gelmeyen paketleri kabul etmediğini, ancak bunlar için ayırma iletileri geri gönderdiklerini belirtir. Eğer alınmamış ancak sırada gelmesi beklenen paketler için de yer ayrılırsa, kilitlenme oluşmaz. Bu adım atlanırsa, uygulama başarısız olabilir.
Ana Bilgisayar Yeniden Gönderimi, Sıralama ve Yinelenenlerin Saptanması
Ana Bilgisayar/Ana Bilgisayar protokolü yeniden gönderim sağlamaz. Ancak sağlasaydı, hedef Ana Bilgisayarın yinelenen iletimleri saptaması ve gelen iletilerin sıralamasını doğrulaması gerekirdi; çünkü hedef IMP, mevcut düzende bir Ana Bilgisayarın yinelenen bir ileti gönderdiğini saptayamaz.
Bu akıl yürütme sürdürüldüğünde, hedef IMP tarafından iletilerin sıralanmasının gereksiz olduğu ve ortadan kaldırılabileceği açıkça görülür. Ayrıca, sıralamanın kaldırılmasıyla birlikte, Ana Bilgisayarlara azami potansiyel bant genişliğine ulaşmak için yeterli sayıda tek paketli ileti gönderme izni verildiği sürece, çok paketli iletiler de ortadan kaldırılabilir.
Ana Bilgisayar yeniden gönderimiyle birlikte, uçtan uca bir tür olumlu onaylama getirilmesi gereklidir. RFNM şu anda hedef IMP tarafından kaynak Ana Bilgisayara gönderilmekte ve bir iletinin hedef Ana Bilgisayara başarıyla teslim edildiği anlamına gelmektedir (çok paketli iletiler için RFNM, ilk paket teslim edildikten sonra gönderilir). Teslimatı doğrulayan Ana Bilgisayar düzeyinde bir onaylama düzenlemek mantıklı görünmektedir. Bu durumda RFNM de ortadan kaldırılabilir.
RFNM’ler isteğe bağlı olarak, açılıp kapatılabilen bir hata ayıklama aracı olarak kullanılabilir.
ARPANET’ten alınan istatistikler, ileti kaybı nedeniyle Ana Bilgisayar yeniden gönderiminin nadiren gerekli olacağını göstermektedir; ancak bu durum kısmen, mevcut IMP sistemindeki yeniden gönderim ve ayırma olanaklarından kaynaklanmaktadır.
Akış Denetimi
Tüm uçtan uca yeniden gönderim, yinelenen saptama ve sıralama işlemleri Ana Bilgisayarlar tarafından yapılacaksa, kaynak ve hedef Ana Bilgisayarların, aynı anda beklemede olabilecek azami paket (ya da bit, sekizli vb.) sayısı üzerinde anlaşmaları zorunludur. Aksi takdirde, hedef Ana Bilgisayar, bugün hedef IMP’de görülenlere benzer kilitlenme sorunları yaşayabilir.
Mevcut Ana Bilgisayar/Ana Bilgisayar akış denetimi düzeninin çeşitli zayıflıkları vardır.
Birincisi, verinin iletildiği bağlantıdan ayrı olan bir denetim bağlantısı üzerinde özel denetim iletilerinin gönderilmesini gerektirir.
İkincisi, bu artımlı bir düzendir; hedef Ana Bilgisayar, kaynak tarafından gönderilebilecek belirli sayıda bit ve ileti ayırır.
Hem kaynak hem de hedef Ana Bilgisayarlar, iletiler gönderilip alındıkça bu sayaçları azaltır. Aktarım hızını korumak için, hedefin, kullanılabilir arabellek alanını yenilemek amacıyla kaynağa periyodik olarak ayırma iletileri göndermesi gerekir. Küçük miktarda arabellek alanına sahip hedefler (örneğin Terminal IMP’leri veya TIP’ler) bunu oldukça sık yapmak zorundadır ve bu nedenle hatırı sayılır miktarda denetim trafiği üretir. Üçüncüsü, bir ayırma iletisinin kaybı ya da yinelenmesi, kaynak ile hedef arasında eşzamanlılığın kaybolmasına neden olabilir.
Daha önceki bir çalışmada [9], yazar ve R. Kahn, Fransız CYCLADES ağında [10] bulunan fikirleri de içeren, daha sağlam bir akış denetimi düzeni önermektedir. Özünde, alıcı, göndericinin iletebileceği sıra numaralarının aralığını temsil eden bir pencere ayırır. Alıcıdan göndericiye giden onaylamalar, şimdiye kadar alınan en büyük sıra numarasını (öncekilerin tümünü örtük olarak onaylayarak) ve ayrıca pencerenin mevcut genişliğini belirtir. Gönderici, sırada hangi sıra numaralarının gönderilebileceğini derhal bilir. Bu düzen ayrıca yinelenenlerin saptanmasına ve iletilerin yeniden sıralanmasına olanak tanır.
Onaylama ve akış denetimi bilgileri, tam çift yönlü bir mantıksal bağlantının ters yönünde akan veriyle birlikte "piggy-back" olarak gönderilir; böylece bu amaç için ayrı bir denetim bağlantısına gerek kalmaz. Örneğin, sıra numarası M ve uzunluğu L sekizli olan bir ileti gönderilir. Alıcı, M + L sıra numarasının onaylaması ve pencere boyutu W ile yanıt verir. Her iletinin sıra numarası, bir önceki iletinin sıra numarasına onun sekizli cinsinden uzunluğu eklenerek elde edilir.
Alıcı, W’nun boyutunu ciddi bir olumsuz etki olmaksızın değiştirebilir ve düzenin izin verdiği yeniden gönderim ve yinelenen saptama sayesinde yinelenenlerin alınmasına ya da iletilerin kaybına dayanabilir.
Göndericinin, sıra numarası, onaylanan son sıra numarası ile mevcut pencere boyutu W’nun toplamını, en büyük sıra numarası artı bir modülüne göre aşacak bir iletiyi iletmesine izin verilmez.
Keyfi İleti Uzunlukları
Şimdiye kadar, kaynak Ana Bilgisayardan hedef Ana Bilgisayara gecikme boru hattını dolduracak yeterli sayıda paket gönderilebildiği sürece, yüksek aktarım hızını sürdürmek için çok paketli iletilerin gereksiz olduğu örtük olarak kabul edilmiştir. Eğer IMP sistemi, Ana Bilgisayar/Ana Bilgisayar protokolü bilgisiyle programlansaydı ve keyfi uzunluktaki bir iletinin başlangıç başlığı verildiğinde ilettiği her paket için doğru biçimlendirilmiş bir Ana Bilgisayar/Ana Bilgisayar başlığı oluşturabilseydi, paketler hedef Ana Bilgisayara sıradan gelmeden teslim edilebilirdi; yeter ki her biri, paketin içerdiği sıra numarası aralığını doğru biçimde tanımlasın. Bir iletinin her sekizlisi örtük bir sıra numarasına sahip olduğundan, bunu hesaplamak zor olmazdı.
Buna benzer bir fikir, mevcut ARPANET’teki Very Distant Host Reliable Transmission Package’ta [ek F, 5] bulunur; ancak bu durumda bir Ana Bilgisayarın IMP paket biçimini bilmesi gerekir. Bunun iyi bir fikir olup olmadığı tartışmalıdır; çünkü Ana Bilgisayar/Ana Bilgisayar protokolündeki değişiklikler, IMP programlamasında da değişiklikler gerektirir. Ancak uygulanırsa, Ana Bilgisayarlar keyfi uzunlukta iletiler gönderebilir. Hedef Ana Bilgisayar, bunları, baştan itibaren kaynak Ana Bilgisayar tarafından bu şekilde gönderilmişler gibi sıralayacağı bir dizi tek paketli ileti olarak alır.
Tek Yönlü ile Tam Çift Yönlü Mantıksal Bağlantılar
Mevcut Ana Bilgisayar/Ana Bilgisayar protokolü tek yönlü bağlantılar uygular. Son beş yıldaki kullanım, çoğu zaman iki tek yönlü bağlantının bir tam çift yönlü bağlantı gibi davranacak şekilde kurulduğunu göstermektedir.
Ana Bilgisayar düzeyinde onaylamalar ve akış denetimi uygulanırsa, bunların tam çift yönlü bir mantıksal bağlantının ters yönünde taşınması doğaldır. Ayrıca, uçbirimden Ana Bilgisayara bağlantılar, verinin her iki yönde de hareket edebilmesi için zorunlu olarak tam çift yönlüdür.
Son olarak, denetimin tam çift yönlü bağlantı üzerindeki geri dönen trafiğin başlıklarına gömülmesiyle, ayrı bir denetim bağlantısına duyulan gereksinim ortadan kaldırılabilir.
Bağlantı Kurulumu
Mevcut Ana Bilgisayar/Ana Bilgisayar protokolü, yeni bağlantılar kurmak için özel bir denetim bağlantısı üzerinde gönderilen denetim iletilerini kullanır. Bu yordam, Initial Connection Protocol ya da ICP [11] olarak adlandırılır. Protokol simetriktir ve bağlantının her iki ucundaki soketlerin adları hakkında her iki Ana Bilgisayar arasında bilgi alışverişini gerektirir. Bu alışveriş, herhangi bir veri akışından önce gerçekleşir. Alıcıda kullanılabilir arabellek alanını belirleyen başka denetim iletileri de değiştirilir.
D. Walden’ın [12] bir önerisi, her iki tarafın da kaynak ve hedef soketleri (Walden bunlara port adını verir) tanımlayan bilgileri, iletilerin metniyle birlikte eşzamanlı olarak gönderebilmesi durumunda bunun büyük ölçüde gereksiz olduğunu öne sürer.
Amaçlanan durumu açıklamak için posta ofisi benzetmesi yararlıdır. Kaynak Ana Bilgisayar bir mektup yazar ve onu, dönüş portu adresi bulunan, hedef porta adreslenmiş bir zarfın içine koyar. Hedef port ya almaya isteklidir ya da değildir (örneğin, hedef Ana Bilgisayar tarafından hiç bilinmiyor olabilir). İlk durumda, mektup olağan şekilde onaylanır. İkinci durumda ise, mektup onaylanmaz (port almaya hazır değildir) ya da reddedilir ("adres bilinmiyor").
Port adresleri, hedef Ana Bilgisayardaki süreçlere dinamik olarak atanabildiğinden, bir alıcı portun kapatıldığını göndericiye bildiren ve göndericinin de bunu onaylamasının beklendiği biçimsel bir denetim alışverişinin eklenmesi muhtemelen gerekli olacaktır. Benzer şekilde, gönderici bir iletimi, gönderme portunun kapatıldığını belirterek sonlandırabilir ve alıcı da bunu aynı şekilde onaylar. Sıralamayı Ana Bilgisayarlar yaptığından, kapanmanın ne zaman gerçekleşeceği konusunda bir karışıklık olamaz. Başlangıçtaki bir iletimin reddi, hedef portun kapatılması gibi gösterilebilir; böylece farklı denetim iletisi türlerinin sayısı en aza indirilebilir. Bu yöntem, şu anda ARPANET’te kullanılan yönteme benzer; ancak Ana Bilgisayar düzeyindeki iletilerdeki denetim bitleri aracılığıyla gerçekleştirilebilir ve böylece özel bir denetim bağlantısına olan gereksinimi ortadan kaldırır.
Özet
Bu çalışmada, çok paketli yeniden birleştirmenin, Ana Bilgisayardan Ana Bilgisayara yüksek aktarım hızına ulaşmak için en iyi araç olmadığına dair savlar sunulmuştur. IMP yeniden birleştirmenin ve hedef IMP tarafından ileti sıralamanın ortadan kaldırılması, IMP protokollerinde önemli bir sadeleşmeye izin verirken, aynı zamanda arabelleğe alma, yinelenen saptama ve ileti sıralama yükünü, bu amaç için arabellek alanına sahip olan Ana Bilgisayarlara yükler.
IMP’nin Ana Bilgisayar protokolü bilgisi pahasına, Ana Bilgisayarlar tarafından keyfi uzunlukta iletiler gönderilebilir. Hedef IMP’de sıralama gereksiniminin ortadan kaldırılması, ciddi potansiyel kilitlenme durumlarını da ortadan kaldırır.
Ana Bilgisayar düzeyinde olumlu onaylamalar, RFNM’nin bu amaçla hatalı kullanımını ortadan kaldırabilir ve IMP alt ağının ileti kaybı olmaksızın kusursuz performansına bağlı olmayan, daha sağlam bir protokole olanak tanır.
Ana Bilgisayarlardaki portlar arasında tam çift yönlü mantıksal bağlantılar, hâlihazırda kullanılan tek yönlü bağlantılardan daha doğaldır ve mevcut Ana Bilgisayar protokolünde gerekli olan özel denetim bağlantısının ortadan kaldırılmasını kolaylaştırır.
Çözülmemiş Sorunlar ve Konular
Bir kaynak ve hedef Host, aralarında çok sayıda iletinin (veya paketlerin ya da oktetlerin) beklemede olmasına izin verecek yeterli tampon alanına sahip olsa bile, IMP alt ağının, bir kaynak Host’tan gelen verinin aşırı hızlı akışından ya da muhtemelen aynı hedefe doğru, aynı yönde ilerleyen aşırı trafiğin birleşmesi nedeniyle ortaya çıkan anlık tıkanıklıklardan kaynaklanabilecek sıkışıklıkla mücadele edebilmenin bir yoluna sahip olması gerekir. Alternatif yönlendirme stratejileri yardımcı olabilir, ancak sorunu tamamen çözemez. Bir olasılık, kaynak Host’ların son birkaç saniye (milisaniye?) içinde elde edilen gerçek aktarım hızını izlemelerini ve buna göre çıkış hızını ayarlamalarını zorunlu kılmaktır. Hedef Host’lar da bu aktarım hızını izleyebilir ve gereksiz yeniden iletimleri azaltmak için göndericiye ayırdıkları alım tamponu alanını buna göre ayarlayabilir. IMP’ler, tamponlanamayan trafiği, kaynağın yeniden iletim yapacağını bilerek basitçe atabilir. Sıkışıklığı gidermek amacıyla paketleri atan IMP’ler, ayarlamayı teşvik etmek için kaynak ya da hedefe (ya da her ikisine) kısa uyarı iletileri bile gönderebilir. Bu son derece zorlu bir problemdir ve Host’ların yeniden iletim için ödeme yapması gibi konuları da içerir. Günümüzde kullanılan stratejilerin çoğu, a priori olarak, bir kaynak Host’un göndermesine izin verilen veri miktarını sınırlamayı içerir (örneğin, Davies [13] tarafından önerilen izaritmik ağ; ARPANET IMP’leri tarafından izin verilen en fazla n ileti). Kaynak ve hedef Host’lar tarafından elde edilen aktarım hızının ölçülmesi, her durumda iyi bir strateji olabilir; çünkü bu, paket anahtarlamalı ağ tarafından sağlanan hizmet kalitesinin bir ölçüsü olarak işlev görür.
ARPANET’te, terminalden Host’a iletişim için kullanılan TELNET protokolü [14], hizmet veren sürecin bulunduğu Host’a, biriken tüm verilerin "kesme sinyali" noktasına kadar atılması gerektiğini bildirecek bir sinyalleme yoluna ihtiyaç duymuştur. Bu olanak, uzak bir kullanıcının, veri kabul etmeyi bırakmış olan işbirliğine yanaşmayan bir hizmet sürecinden kontrolü iptal etmesine ya da yeniden ele geçirmesine izin verir. Mevcut düzenek, kontrol bağlantısı üzerinden gönderilen özel bir kesme sinyalinin kullanımını içerir; ancak kesme isteğini hat içindeki verilerle eşzamanlama sorunu vardır. Bu sinyal, bir Host iletisinin kontrol alanında taşınabilir ve verinin sıra numaralandırmasına katılabilir; böylece eşzamanlama sağlanmış olur. Host işletim sistemi, veriyi alıcı porta iletmeden önce ileti başlığını işleyeceğinden, kesme sinyali alıcı süreç tarafından yapılan işlemleri baypas edebilir ve böylece istenen kesme benzeri etkiyi sağlayabilir.
Bu makalenin kapsamı içinde değinilemeyen, kuşkusuz daha birçok problem ve konu vardır; yazar, bunların ve yukarıdaki yorumların tartışmayı teşvik etmesini ve böylece dağıtık bilgisayar ağları için protokol gereksinimlerinin genel olarak anlaşılmasını ilerletmesini memnuniyetle karşılayacaktır.
Teşekkürler
Aktarım hızı ve gecikme analizi: bu analizdeki temel fikirlerin bir kısmı J. McQuillan’a (Bolt, Beranek, and Newman) aittir. Tek paket yeniden sıralama kilitlenmesi: ilk kez yazarın dikkatine P. Higginson (University of London) tarafından sunulmuştur. Host-Host Protokol Tasarımı: büyük ölçüde International Network Working Group (IFIP TC6.1) himayesinde geliştirilmiştir ve yazar özellikle R. Kahn, R. Metcalfe, L. Pouzin ve H. Zimmerman’ın yanı sıra S. Crocker, A. McKenzie ve R. Scantlebury’nin katkılarını kabul etmektedir. Çok sayıda eksiklik ve yanlış ifade R. Kahn, L. Kleinrock ve H. Opderbeck tarafından tespit edilmiştir.
Yazar, DAHC-15-73C-0435 numaralı sözleşme kapsamında Defense Advanced Research Projects Agency’nin desteği için minnettardır.
Kaynaklar
McKenzie, A. "ARPA Ağı için HOST/HOST Protokolü," Current Network Protocols, Network Information Center, Stanford Research Institute, Menlo Park, California, Ocak 1972 (NIC 8246).
Carr, S., S. Crocker ve V. Cerf, "ARPA Ağında HOST-HOST İletişim Protokolü," AFIPS 1970 SJCC Proceedings, Cilt 36, Atlantic City, AFIPS Press, New Jersey, ss. 589–597.
Crocker, S. D., J. Heafner, R. Metcalfe ve J. Postel, "ARPA Bilgisayar Ağı için İşlev Odaklı Protokoller," AFIPS 1972 SJCC Proceedings, Cilt 40, Atlantic City, AFIPS Press, New Jersey, ss. 271–279.
Heart, F. E., R. E. Kahn, vd., "ARPA Bilgisayar Ağı için Arayüz İleti İşlemcisi," AFIPS 1970 SJCC Proceedings, Cilt 36, Atlantic City, AFIPS Press, New Jersey, ss. 551–567.
Bolt, Beranek and Newman, Inc., "Bir Host ile bir IMP’nin Birbirine Bağlanması için Şartname," BBN Raporu 1822, Nisan 1973 (Gözden Geçirilmiş).
Roberts, L. ve B. Wessler, "Kaynak Paylaşımını Sağlamak için Bilgisayar Ağı Geliştirme," AFIPS 1970 SJCC Proceedings, Cilt 36, Atlantic City, AFIPS Press, New Jersey, ss. 543–549.
Kahn, R. E. ve W. Crowther, "Kaynak Paylaşımlı Bir Bilgisayar Ağında Akış Kontrolü," Second Symposium on Problems in the Optimization of Data Communications Systems, Palo Alto, Ekim 1971, ss. 108–116; ayrıca IEEE Transactions on Communication, Haziran 1972.
Kahn, R. E., "Kaynak Paylaşımlı İletişim Ağları," IEEE Proceedings, Kasım 1972.
Cerf, V. G. ve R. E. Kahn, "Paket Ağlarının Birbirleriyle İletişimi için Bir Protokol," IEEE Transactions on Communication, Cilt COM-22, No. 5, Mayıs 1974, ss. 637–641.
Pouzin, L., "CYCLADES Bilgisayar Ağının Sunumu ve Başlıca Tasarım Yönleri," Data Networks: Analysis and Design, Third Data Communications Symposium, St. Petersburg, Florida, Kasım 1973, ss. 80–87.
Postel, J., "Resmî Başlangıç Bağlantı Protokolü," Current Network Protocols, Network Information Center, Stanford Research Institute, Menlo Park, California, Ocak 1972 (NIC 7101).
Walden, D., "Kaynak Paylaşımlı Bir Bilgisayar Ağında Süreçler Arası İletişim için Bir Sistem," Communications of the ACM, Cilt 15, No. 4, Nisan 1972, ss. 221–230 (NIC 9926).
Davies, D., "Hızlı Tepki Veren Bilgisayarlar için Hizmet Sunan İletişim Ağları," Information Processing 68, IFIP Congress 1968 Bildirileri, Cilt 2, Edinburgh, İskoçya, North-Holland Publishing Co., Amsterdam, 1969, ss. 650–658.
McKenzie, A., "TELNET Protokol Şartnamesi," Current Network Protocols, Network Information Center, Stanford Research Institute, Menlo Park, California, Ağustos 1973 (NIC 18639, NIC 18638 – Revizyonlar).